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DESCRIPTION 

SECURE LOGGING OF TRANSACTIONS 

The present invention relates to the logging of transactions between two 
or more data processing devices, and in particular to establishing a secure log 
In respect of each transaction between the devices. 

The use of digital^ siggatures using public key cryptography to enable 
verification of . the authenticity and tntegrity of data transmitted between first 
and second parties is well known. 

A commonly used method Is for the first party to apply a one-way hash 
function to the data that is to be conveyed to the second party. The resulting 
hash code can then be encrypted using the private key of the first party, and 
transmitted to the second party as a "signature" together with the original data. 
The second party can apply the same hash function to the original data and. 
having knowledge of the first party's public key can also decrypt the encrypted 
hash code (the "signature") using the first party's public key. if the two 
versions of the hash code match, the second party can be confident (i) that the 
data does indeed come from the first party (ie. the authenticity is verified) and 
(ii) that the data has not been interfered with or corrupted en route (ie. the data 
integrity is verified). 

There are a large number of applications and systems in which access 
control devices connected to computer networks provide secure control of 
access to certain functions by third party devices. The control is generally 
effected by the third party devices providing Identification and other data (often 
encrypted) to the control devices which then establish from that data whether 
use of the function is authorised or not authorised. 

A typical example of such a system is for physical access controf to a 
large building using "smartcards" or "cardkeys". In this system, personnel 
requiring access to the building each cany a cardkey that provides an 
identifying password (key) to entry point access control devices (eg. electronic 
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locks) installed at each access control point of the building (eg. both external 
and Internal access doors). The access control devices then deten^iihe, on the 
basis of received password keys, whether to grant access (eg. unlock the 

door). - . 

5 It is often necessary or highly desirable to record all transactions 

* between two devices, such as the cardkeys and the access control devices, so 
that the resulting transaction log may be used to establish who gained access 
to. the building, at which access point, and when. Commonly, the access 



the verified identities of both parties, but also an agreed or verified time stamp. 

It is an object of the present invention to provide a secure transaction 
15 logging system in which the transaction log can be verified for authenticity and 
data integrity by both devices that are party to the transaction. In this way, the 
transaction log can contain transaction data that has been verified by both 
devices that were party to the transaction. 

It is a further object of the invention to provide a secure transaction 
20 logging system in which the transaction log can be verified for authenticity and 
data integrity by third parties having knowledge of the public keys of the 

devices that were party to a transaction. 
lt-is-a-fupther-objeGt-of-the_present_inv.ention_to_prQyjde_a_se.c.uLe_ 

transaction logging system in which data associated with the transaction, eg. 

25 time stamp data, may be recorded separately and securely as verified by both 

parties. 

In this way, interi'erence with either device, or. with the data as it is 
transmitted to a central control computer, can be detected. In addition, theft of 
password data for use on a non-authorised device, or comjption of transaction 
30 data can also be detected. 
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transaction log would be stored. 

In addition, it is often desirable not only that the transaction log records 




3 



P4GB 020141 



According to one aspect, the present Invention provides a metliod of 
generating a secure transaction log recording transaction data established 
between a first and a second data processing device, comprising the steps of: 

the first device issuing a partial transaction log to the second device, the 
partial transaction log including identification data and event data associated 
with the transaction; 

the second device issuing to the first device, in response to the partial 
transaction log, a signed full log, the signed full log Including said identification 
data and event data, secured, by a first digital signature specific to the second 
device; and ' 

the first device issuing, in response to the signed full log, a re-signed full 
log including said identification data, said event data and said first digital 
signature, secured by a second digital signature specific to the first device. 

According to another aspect, the present invention provides a nnethod 
of operating an access control device to generate a secure transaction log 
recording transaction data established between a first device and the access 
control device, comprising the steps of: 

receiving from the first device, a partial transaction log, the partial 
transaction log including identification data and event data associated with the 
transaction; 

issuing to the first device. In response to the partial transaction log, a 
signed full log, the signed full log including said Identification data and event 
data, secured by a first digital signature specific to the access control device; 
and 

receiving, fi'om the first device. In response to the signed full log, a re- 
signed full log Including said Identification data, said event data and said first 
digital signature, secured by a second digital signature specific to the first 
device. 

According to another aspect, the present invention provides a method 
of operating a first data processing device to generate a secure transaction.log 
recording transaction data established between the first device and a second 
data processing device, comprising the steps of: 
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issuing a partial transaction log to the second device, the partial 
transaction log including identification data and event data associated with the 
transaction; 

receiving from the second device, in response to the partial transaction 
5 log, a signed full log. the signed full log including said identification data and 
event data, secured by a first digital signature specific to the second device; 
and 

issuing, in response to the signed full log. a re-signed full log including 
said identification data, said event data and said first digital signature, secured 
10 by a second digital signature specific to the first device. 

According to another aspect, the present invention provides apparatus 
for generating a secure transaction log recording transaction data established 
between a first and a second data processing device, comprising:. 

means, in the first device, for issuing a partial transaction log to the 
15 second device, the partial transaction log including identification data and 
event data associated with the transaction; 

means, in the second device, for issuing to the first device, In response 
to the partial transaction log, a signed full log, the signed full log including said 
identification data and event data, secured by a first digital signature specific to 
20 the second device; and 

means, in the first device, for issuing, in response to the signed full log, 
a re-signed full log including said identification data, said event data and said 
first-digitai-signatuferseeured-by-a-seGond-digital-signature-speciflc-to-the-ficsL 

device. 

25 According to another aspect, the present invention provides an access 

control device adapted to generate a secure transaction log recording 
transaction data established between a first device and the access control 

device, comprising; 

means for receiving from the first device, a partial transaction log, the 
30 partial transaction log including identification data and event data associated 
with the transaction; 
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means for Issuing to the first device, in response to the partial 
transaction log. a signed full log, the signed full log including said identification 
data and event data, secured by a first digital signature specific to the access 
control device; and 

means for receiving, from the first device, in response to the signed full 
log, a re-signed full log including said identification data, said event data and 
said first digital signature, secured by a second digital signature specific to the 
first device. 

' * . • 

According to another aspect, the present invention provides, a data 
processing device adapted to generate a secure transaction log recortlirig 
transaction data established between the data processing device and a 
second data processing device, comprising: 

means for issuing a partial transaction log to the second device, the. 
partial transaction log Including identification data and event data associated 
with the transaction; 

means for receiving from the second device, in response to the partial 
transaction log, a signed full log, the signed full log including said identification 
data and event data, secured by a first digital signature specific to the second 
device; and 

means for issuing, In response to the signed full log, a re-signed full log 
including said Identification data, said event data and said first digital 
signature, secured by a second digital signature specific to the data 
processing device. 

Embodiments of the present invention will now be described by way of 
example and with reference to the accompanying drawings in which: 

Figure 1 shows a schematic block diagram of apparatus suitable for 
implementation of transaction logging procedures as described herein; 

Figure 2 shows a schematic flow diagram of a secure transaction 
logging procedure between two devices; 

Figure 3 shows a schematic flow diagram of a secure transaction 
logging procedure between three devices; and 
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Figure 4 shows a schematic diagram of apparatus for one application of 
the secure transaction logging process of figure 2. 

With reference to figure 1 , apparatus suitable for Implementing a secure 
transaction logging process between at least two devices 10, 20 will now be 
described. 

A first device 10 includes a processor 11 and a memory 12. The 
processor 11 is particularly configured to handle data processing transactions ' 
between the first and the second devices, including the application of a digital 
signature specific to the first device 10 to data transmitted to the second 
device 20. The processor 11 may, therefore, include a specific cryptographic 
engine, or the cryptographic functions may be perfonmed .by a general purpose 
, processor. . ' 

The memory 12, which may be of any suitable type or types, Includes 
storage capacity necessary for handling data processing transactions with the 
second device 20 or other device (not shown). In particular, the memory 12 
preferably includes an identification data register 13 storing identification data 
by which the device 10 may be identified, and this may be in unencrypted or 
encrypted form. The memory 12 further preferably includes a key register 14 
which contains the public keys of ail other devices with which the device 10 
may need to communicate, for decrypting digital signatures and/or encrypted 
communications thereof. The key register 14 may also include the private key 
— spBcificio-the^evice-10rfor-signing-messages-outgoingJrom-th.e.deyip.e^ 
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The memory 12 preferably also includes a transaction log register lb 
25 that maintains a log of all relevant transactions with other devices 20. 

The first device may also include a real time or other clock 16. In 
general, the expression "clock" is intended to Include any transaction counter 
or mechanism marking temporally spaced events in a time domain of the first 
device. 

A second device 20 also includes a processor 21 and a memory 22. 
The processor 21 is also particularly configured to handle data processing 
transactions between the first and the second devices, including the 
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application of a digital signature specific to the second device 20 to data 
transmitted to the first device 10. The processor 21 may, therefore, Include a 
specific cryptographic engine, or the cryptographic functions may be 

performed by a general purpose processor. 

5 The memory 22, which may be of any suitable type or types, includes 

storage capacity necessary for handling data processing transactions with the 
. first device 20 or other devices (not shown). In particular, the memory 22 
preferably includes an identification data register 23 storing identification data 
by vyhich the device .20 may be identified, and this may be In unencrypted or 

10 encrypted form. The memory 22 further preferably includes a key register 24 
which contains the public keys of all other devices with which the device 20 
may nised to communicate, for decrypting digital signatures thereof. ' The key 

- - register 24 may also include the private key specific to the device 20, for . 
signing messages outgoing from the device. 

15 The memory 22 preferably also includes a transaction log register 25 

that maintains a log of all relevant transactions with other devices 10. 

The second device may also include a real time or other clock 26. In 
general, the expression "clock" is intended to include any transaction counter 
or mechanism marking temporally spaced events in a tinrie domain of the 

20 second device. 

It will be understood that, although only two devices 10, 20 are 
illustrated, the principle of the transaction logging process can apply between 
any two or more devices in a group of devices. 

• The devices 10, 20 are adapted to communicate with one another over 

25 any suitable communications channel 30. 

For example, the comrnunications channel 30 may be a permanent or a 
transient direct electrical connection between the devices, or may be an 
optical, infrared, RF, electromagnetic or inductive link, for example in the case 
where one device 10 is a cardkey and the other device 20 is an electronic door 

30 lock. On the other hand, the communications channel 30 may be a permanent 
or transient network connection in the event that the devices are networkable 
computer systems. 
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In another embodiment, the second device 20 may be connected via a 
second communications channel 31 to a server 40 that may be used to insert 
third party data within transaction logs between the first and second devices 
.10,. 20. The communications channel 31 may be any suitable, rneans for 
5 transferring data, preferably a networl^, and more preferably the internet. 

As previously described in connection with the first and second devices 
10, 20, the server 40 preferably includes a processor 41 and a memory 42. 
The processor 41 is particularly configured to handle data processing 
trahsactipns with the second (or other) devices 20, including the application of 
10 a digital signature specific to the server to secure. data transmitted to. the 
. second device. The processor 41 may, therefore, include a specific 
cryptographic engine, or the cryptographic functions may be performed by a 

. general purpose processor. - . . 

The memory 42. which may be of any suitable type or types, includes 
15 storage capacity necessary for handling data processing transactions with the 
second device 20 or other devices (not shown). In particular, the memory 42 
preferably Includes an identification data register 43 storing identification data 
by which the server 40 may be identified, and this may be in unencrypted or 
encrypted form. The memory 42 further preferably includes a key register 44 
20 which contains the public keys of all other devices with which the sender 40 
may need to communicate, for decrypting digital signatures thereof. The key 
register 44 may also include the private key specific to the server 40, for 
-signing-messages-outgoing-from-the-seFver^ 




The memory 42 preferably also includes a transaction log register 45 
25 that maintains a log of all relevant transactions with other devices 1 0, 20. 

The server 40 may also include a real time or other clock 46. In 
general, the expression "clock" is intended to include any transaction counter 
or mechanism marking temporally spaced events in a time domain of the 
server, which may be Independent of the time domains of either or both of the 
30 first and second devices. 

In preferred embodiments, the first device 10 may be a portable candkey 
type device for allowing a user access to a facility, premises or resource, such 
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as a building, restricted area, computer resource or the like. In such a case, 
the second device 20 may be an access control device such as an electronic 
door lock, gate lock, equipment control system or a computer system. 

In a general aspect, the access control device may be any device which 
effectively provides a transaction service to the first device, which service may 
include access to physical entities or virtual entities such as data, program 
code, computing resource or financial services. The server 40 may be a 
centra! control computer effecting access control for th^ entire building, facility, 
or resource. In^ prefen-ed arrangements, the server 40 Is an Independent 
auditor, witness, timekeeper or log keeper. It may also form part of the same 
system as that of the second device. It may also be operated and/or owned by 
a trusted third party organisation completely independent of the owners and/or 
operators of the first and second devices. 

In another embodiment, the first device 10 may be a portable user 
identification device, such as a smartcard, credit card, debit card or the like, 
and the second device 20 may be a vending machine, retail point of sale 
terminal or other commercial transaction recording device. The server 40 may 
be a credit authorisation computer system. 

In another embodiment, the first device 10 may be a computer or data 
processing disvice seeking to retrieve data from the second device, which 
could be a database or server. 

Turning now to figure 2, a first transaction procedure 50 will now be 
described. 

In a first step, the first device 10 issues a request 51 to the second 
device 20 Initiating a transaction between the two devices. The request may 
include a transaction type specifier (indicating the type of transaction 
requested) and Identification data Identifying the originating device 10. 

In a second step, the second and first devices may generally 
communicate to an extent necessary to determine the nature of the transaction 
required and any data essential thereto, to establish the necessary 
authorisation required, and any other communication as required. For 
convenience, this step will generally be refen-ed to as an authentication / 
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negotiation stage 52. but this is not to imply any linnitation on the information 
flow effected. 

This stage of the transaction may include processing of any data 
nece_s:sary by. either device, and the data transmitted between the devices may . 
5 be encrypted, unencrypted or a combination of both. The data may be 
accompanied by a digital signature of the sending device, if desired. It will be 
understood that, for the purposes of the present invention, the exact details of 

^ "" ■ ' 

the transaction are not essential. 

In a third step, the first device 1 0 generates a partial log message 53 for 
transmission to. the second device 20. The partial log message 53 effectively 
contains any data that are required to adequately record details of the 
transaction in a transaction log, but particulariy including data identifying the 
first device and.eventdata relating tp the.transaction. The partial log 53 may 
be transmitted to the second device 20 in an encrypted and/or signed form, but 

15 need not be so. 

In a fourth step, the second device 20 receives the partial log message 
53 from the first device 10 and verifies that it is satisfied with the contents as 
being a correct representation of the transaction details. 

If necessary, the second device may add further identification data (eg. 
its own identity) and/or further event data relating to the transaction, if this is 
not already present in the partial log 53. 

If necessary, the second device may change information provided by 
th^irrstrdevice-i^itHs-nert-satisfied-AAfith-the-contents_ofibe_partialJ^^^ 
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53 provided by the first device. 

25 The second device thereby generates a full log message 54 for 

transmittal to the first device. Prior to sending the full log message, the second 
device appends a digital signature to the full log message thereby ensuring the 
security of the full log message, and indicating its approval of the contents. 

It will be understood that the application of a signature may include 

30 encryption of the entire message. However, in a general aspect, the signed 
full log includes identification data and event data for the transaction secured 
by a first digital signature that is specific to the second device 20. This 
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ensures that the signed full log 54 received by the first device can be verified 
for authenticity and data integrity. 

Upon receipt of the signed full log 54, the first device 10 verifies the 
integrity of the signed full log using the digital signature, and then re-signs the. 
5 full log 54 to generate a re-signed full log 55 to be transmitted to the second 
device. ^ 

It will be understood that, in the verification of the signed full log 54, the 
first device should check that it agrees with any additions / deletions / changes 
to the parti^ log 53 that have been made by the second device, prior to re- 
10 signing the full log to generate the re-signed full log 55. 

It will be understood that the application of the second digital signature 
by the first device may include encryption of the entire message. However, in 
a general aspect, the re-signed full log 55 includes the original identification, 
data and event data for the transaction as secured by the first digital signature 
15 that is specific to the second device 20, and then secured by a second digital 
signature that is specific to the first device 10. This ensures that the re-signed 
full log 55 received by the second device can be verified as authentic and 
having data integrity by the second device. 

The re-signed full log 55 is stored in memory 25 by the second device. 
20 Either the re-signed full log 55, or the signed full log 54 is stored in memory 15 
by the first device. 

It will recognised that, at this point, both the first and second devices 10, 
20 have a copy of a transaction log 55, 56 that is verified as a true account of 
the transaction by both parties. No corruption of, or interference with, this data 
25 is possible by either party or by an independent third party without the 
corruption being evident to either device that signed or re-signed the 
transaction log. 

In typical embodiments, the transaction being effected (eg. obtaining of 
access to a resource by the first device) may be prohibited from completion 
30 until such time as the second device receives a re-signed full log 55. Upon 
receipt of the re-signed full log, the second device may authorise the 
necessary action that completes the transaction 56. 
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Where the transaction relates to access control, the re-signed 

transaction log 55 may include identification data identifying the accessing 

party and the controlling party, and event data indicating the location of the 

access to the restricted resource, the time and date of the access, the 

5 authorisation level used for the access, and any other important transaction 

♦ 

information. 

Where the transaction relates to the purchase of commodities, either 
from a vending machine or a point of sale terminal, the re-signed transaction 
log may Include identification data identifying both parties to .the transaction, 
10 and event data indicating the location of the sale, the amount of the sale 
and/or the commodities purchased. 

Preferably, the signed log and / or the re-signed log will include a 
• unique identification code that can be referenced.. 

In a variation in the procedure of figure 2. the first device 10 may 
15 disagree with the contents of the signed full log 54. This could be as a result 
of additions, amendments or deletions made to the partial log 53 by the 
second device 20, or because the first device cannot verify the authenticity of 
the digital signature applied to the signed full log by the second device. 

In this Instance, the first device may issue a further partial log. which 
20 could be the same as the first partial log, or preferably a revised partial log that 
incorporates changes consequent on the data received from the second 
device in the signed full log 54. In any event, this procedure will initiate a 

There is no practical limit to the number of times that the steps of generating a 
25 partial log 53 and a signed full log 54 can be repeated during a negotiation 
process in which the first and second devices try to agree upon a log. 

Protocols may be implemented for ascertaining how to reach an 
agreement in the event that conflicts occur between the first and second 
devices. Similarly, protocols may be implemented for determining when to 
30 abort attempts to reach agreement and abandon the transaction. 

With reference to figure 3 a more complex second transaction 
procedure 60 will now be described. 
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. Like the first transaction procedure 50, in a first step, tlie first device 10 
issues a request 61 to the second device 20 initiating a transaction between 
the two devices. 

Again, like the first transaction procedure 50, in a second step, the 
second and first devices may generally conamunicate to an extent necessary to 
. determine the nature of the transaction required and any data essential 
thereto, to establish the necessary authorisation required, and any other 
comrxiunication as required. For convenience, this step is again referred to as 
an autifentication / negotiation stage 62, but this is; not to imply any limitatipn 
on the ihforma|ion flow effected. 

This stage of the transaction, may . Include processing of any data 
necessary by either device, and the data transmitted between the devices may 
be encrypted,, tjnencrypted or a combination of both. The data, may be 
accompanied by a digital signature of the sending device, if desired. It will be 
understood that, for the purposes of the present invention, the exact details of 
the transaction are not essential. 

In a third step, the first device 10 generates a partial log message 63 for 
transmission to the second device 20. The partial log message 63 effectively 
contains any data that are required to adequately record details of the 
transaction In a transaction log, but particularly including data Identifying the 
first device and event data relating to the transaction. The partial log 63 may 
be transmitted to the second device 20 in an encrypted and/or signed fonn, but 
need not be so. 

Device 20 examines the partial log, and may add to, remove from or 
edit data in the log as required. For example, device 20 may add its own 
device Identification, timing information, etc. 

At this point, the procedure departs from that of figure 2. In a fourth 
step, the second device 20 generates a fill log request 64 to a third party 
server 40. The fill log request generally comprises the contents of the partial 
log 63 (possibly as edited by device 20) and a request for third party data for 
Inclusion in the transaction log. 
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The fill log request 64 may Include a request for an Independent verified 
time stamp from a trusted third party, where a time stamp Is Important to verify 
the transaction. This may be desirable to ensure evidence of any tampering 
with the internal clocks of either one or both of the first or second devices 10. 
5 20 during execution of the transaction. 

' , ■ The fill log request 64 may include a request for an authorisation code 
from the sen/er 40. For example, where the transaction relates to purchase of 
a commodity by credit card. tTie authorisatidn code may be the credit card 
provider's, transaction" authorisation for an amount of credit established during 
id'"*-the transaction. It will be understood that, in a general aspect, the fill log 
request may be ponsidered as equivalent to a partial log request from the 
second device to a server or third device. 

. In a jfth .step, the server 40 returns a signed log 65 to the second . 
device 20. the signed log including the requested information from the server. 
15 The information (eg. the trusted third party time stamp, or the transaction 
authorisation code) is secured by appending a digital signature of the server to 
the log returned to the second device 20. The signed log may include 
identification data identifying the server 40. The signed log 65 may be 
encrypted or unencrypted. The server may generally add, subtract or alter 
20 data in the fill log request 64 prior to generating a signed log 65. 

In a sixth step, the second device 20 receives the signed log message 
65 ft-om the server 40 and verifies that it is satisfied with the contents as being 
a ^rr^H rap^^i^noT the transactlQTrdetailsr-and-that-the-message-ls- 
authentic using the digital signature from the server. If necessary, the second 
25 device may add ftjrther identification data (eg. its own identity) and/or further 
event data relating to the transaction, providing that it does not interfere with 
• any portion of the log that is signed by the server, since that would Invalidate 
any such portion of the log signed by the server. The second device 20 
thereby generates a full log message 66 for transmittal to the first device 10. 
30 Prior to sending the full log message, the second device appends a digital 
signature to the full log message thereby ensuring the security of the full log 
message 66, and indicating its approval of the contents. 




t 
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The second device should not, however, Interfere with the-data provided 
by the server 40 if it Is in agreement with it. it is necessary that the integrity 
and authenticity of the sen/er-provided data can be verified by the first device. 
If the second device is not in agreennent with data provided by the server 40 in 
the signed log 65, the second device can repeat a fill log request 64, abort the 
transaction, or initiate a restarting of the transaction, according to any suitable 
defined protocol. 

It. will be understood that the application of a signature may include 
encryption of the entire message. However, in a general aspect, the signed 
full log message 66 Includes identification data and event data for the 
transaction, secured by a digital signature specific that is to the server 40, and 
further secured by digital signature that is specific to the second device 20. 
This ensures that the signed full log received by the first device can be verified 
as authentic and having data integrity with respect to both data elements that 
have originated from the server and from the second device. 

Upon receipt of the signed full log 66, the first device 10 verifies the 
integrity of the signed full log using the digital signatures, and checks that it 
agrees with the content of the log. it then re-signs the full log to generate a 
re-signed full log 67 to be transmitted to the second device 20. 

It will be understood that the application of the digital signature by the 
first device 10 may include encryption of the entire message. However, in a 
general aspect, the re-signed full log 67 includes the original identification data 
and event data for the transaction as secured by the digital signature that is 
specific to the server 40, the digital signature that is specific to the second 
device 20, and the digital signature that is specific to the first device 10. 

The re-signed full log 67 is stored in memory 25 by the second device. 
Preferably, the re-signed full log 67, or possibly the signed full log 66, is stored 
In memory 1 5 by the first device. However, if only the signed full log 66 is 
stored by the first device, that does not provide subsequent evidence in the 
domain of the first device that the final log was agreed, except by its stored . 
presence in the first device. 
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It will recognised that, at this point, both the first and second devices 10. 
20 have a copy of a transaction log 66. 67 that Includes third party trusted 
information or. more generally, server information, that Is also verified as a tme 
account of the transaction by both partjes,.. No comjptlon of. or interference 
5 ' with, this data is possible by either party or by an independent third party 
without the corruption being evident to either device that signed or re-signed 
the transaction log. 

. ' ' ■ if it Is necessary or desirable to do so. the re-signed full log 67 may also 
be fonA^arded. to the server 40 to maintain an Independent secure log of the 
10 transaction. 

In other respects, .the second transaction procedure 60 Is similar to the 
first transaction procedure. 

In typical embodiments.. the.transg.ctiQn being effectpd (eg. obtaining of 

access to a resource by the first device) may be prohibited from completion. 
15 until such time as the second device receives a re-signed full log 67. Upon 
receipt of the re-signed full log. the second device may authorise the 
necessary action that completes the transaction 68. 

it will be understood that a variation in the procedure of figure 3. where 
the first device disagrees with additions, amendments or deletions made by 
20 the second device when generating the signed full log. can be effected in an 
analogous fashion to that already described in connection with figure 2. The 
first device can re-issue a revised partial log 63 and the third, fourth, fifth and 




been provided by the server 40 Is not disputed, it may not be necessary to 
25 repeat the fourth and fifth steps (fill log request message 64 and signed log 
message 65), merely repeating the third and sixth steps. 

It will be understood that In some very simple transactions, the initial 
request 51. 61 might be incorporated into the partial log message 53. 63. In 
this instance, the authentication / negotiation stage 52 may effectively also be 
30 Incorporated into the partial log message 53. 63 and the signed fijil log 
message 54. 66. 
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In preferred embodiments, the partial log message 53, 63 may include 
one or more of: a unique device Identifier for the first device 10; an indication 
of the authorisation level of device 10; a first transaction identifier; a 
specification of the transaction type; a time of the transaction according to a 
clocl< in the time domain of the first device; any other data specific to the 
transaction. . , * 

In preferred embodiments, the signed full log message 54, 66 may 
ihclude one or more of: the Information of the partial log message; a unique 
device identifier for the second device 20; a second transaction identifien a 
time of the transaction according to a clock In the time domain of the second 
device; any other data specific to the transaction. 

In prefenred embodiments, the signed full log message 66 may also 
.. include . secured data" from the server... 40. Including one or rnore .of: 
independent time and/or date infomiation according to the time domain of the 
server; a transaction Identifier; an authorisation code; any other data specific 
to the transaction. 

In some circumstances, it may be desirable to provide notification of the 
precise time at which access is granted, le. the time at which the transaction 
completes. This can be effected by way of separate messages which are 
issued by the second device using secured or unsecured data. 

With reference to figure 4, in one preferred embodiment for use in home 
security, the first device 10 may be a cardkey for access to a building, the 
second device 20 may be an electronic lock, and the server 40 may be a 
computer coupled to the second device, and preferably also to the Intemet. 
The communication channel 30 between the key 10 and the lock 20 may be 
direct electrical communication. The communication channel 31 between the 
electronic lock 20 and the computer 40 may be by wireless (eg. Bluetooth) link. 

The cardkey 10 may. be used by an authorised person, such as a 
gardener or domestic assistant. The electronic lock 20 will determine whether 
access to the premises to that person is accepted. In a first arrangement, the 
access may be granted autonomously by the electronic lock, and a log of the 
transaction (entry of the person to the building) recorded both In the electronic 
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lock and in the cardkey. The electronic lock 20 may also communicate the 
transaction to the computer 40. which may be accessible to a homeowner 45 
or building supervisor remotely via the internet. 

' In a second arrangement, the electronic lock 20 may not be able to 
5 grant access autonomously, but may need to obtain a transaction 
authorisation from the server 40. This authorisation might be granted by the 
computer (which may be remotely configurable via the internet) or the 
authorisation may need real time approval from the homeowner 45 or building ' 
supetvisor. . In this Instar^ce. the computer 40 may communicate with the 
10 homeowner 45 via internet e-mail, mobile telephony, or text riiessaging.. 

It will be understood that the principle of the invention can be extended 
to more devices, eg where three or more devices are party to a transaction. In 
this case, each device has the opportunity to verify a digitally signed copy of 
the transaction log from each of the other devices party to the transaction. 
15 For example, referring again to figure 3. one implementation using 

multiple parties is now described. After receiving a fill log request 64 and • 
adding any infonnation to the partial log that is required, the server 40 may 
pass this partial log (that is, make a further fill log request 64) onto a second 
server. This second server would add its infonnation to the log, sign it and 
20 return it as a signed log 66 to the first server 40. The first server 40 could then 
validate the signed log from the second server, sign it itself, and return the log 
to the second device 20. This would not affect the overall process from the 
~ p oint of- ^w th» fiF^^Ha^econg--devi^^^^^ 

also be repeated for any number of nested third parties. 
25 A multiple party arrangement could also be Implemented in respect of 

first, second and third (or more) devices, extending the embodiment of figure 
2. For example, one such device (for example, the second device 20) could 
forward multiple parallel partial logs to other parties for verification and 
signature and compile all signed logs received from each other party into one 
30 signed full log 66 message for return to the first device. This parallel approach 
would ensure agreement of the whole log by two of the parties, but not the 
other parties. 
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Full agreement of the log by ail parties could be effected in an N-device 
transaction log by way of a series approach to the set of messages. A first 
device issues a partial log to a second device, and this is passed 
consecutively to every other device to amend or add to in a fonward direction. 1 . 
5 ... N. At the end of the chain, the Nth device signs the log and returns the full 
log to each of the N-1 devices consecutively in the reverse direction; Once the 
first device has. received the full log signed by ail parties, It may pass the re- 

, * signed jog 67 back down the chain in a fonward direction 

QVnpT embodiments are Intentionally within the scope of the accompanying 

10 claims. 
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CLAIMS 

1. A method of generating a secure transaction log recording transaction 
data established between a first and a second data processing device, 

5 comprising the steps of: 

the first device issuing a partial transaction log to the second device, the 
partial transaction log including identification data and event data associated 
with the transaction; . 

^e second device issuing to the first device, in response to the partial 
10 transaction log, a signed full log, the signed full log including said identification 
data and event data, secured by a first digital signature specific to the second 
device; and 

the. first device .issuing, in response to the signed full log, a re-signed full. 

log including said identification data, said event data and said first digital 
15 signature, secured by a second digital signature specific to the first device. 

2. The method of claim 1 further including, prior to the step of issuing the 
partial transaction log, the step of: 

establishing communication between the first and second devices in 
20 order to effect a transaction and generate data associated with that 
transaction, at least some of the data so generated being used as said event 
data in said partial transaction log. 



3. The method of claim 2 in which the transaction includes authentication 
25 of the identity of at least one of the devices. 

4. The method of claim 1 in which the event data includes time stamp 
information derived from at least one of the first device and the second device. 

30 5. The method of claim 1 in which the event data and/or the further event 
data includes time stamp information derived from both the first device and the 
second device. 
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6. The method of claim 1 in which the identification data includes data 
uniquely identifying the first device and/or the second device. 



7. The method of claim 1 in which the signed full log Includes further event 
data added by the second device. 

8. The method of claim 1 in which at least one or more of: the partial log; 
the signed transaction, log; and the re-signed transaction log are encrypted 
during transfer between the first and second devices. 

9. The method of claim 1 in which the first digital signature is applied using 
a private key of the second device, the counterpart public key being, accessible. 
to the first device. 

1 0. The method of claim 1 or claim 9 in which the second digital signature is 
applied using a private key of the first device, the counterpart public key being 
accessible to the second device. 

1 1 . The method of claim 1 further including the steps oft 

Issuing a data request to a third device, by the second device, after 
receiving the partial transaction log from the first device; 

receiving third party event data, by the second device from the third 
device in response to the data request; 

including the third party event data into the signed full log issued to the . 
first device. 

12. The method of claim 1 1 in which the third party event data is secured by 
a third digital signature specific to the third device. 

13. The method of claim 1 1 In which the third party event data includes time 
stamp infomnation independent of the first and second devices. 



5 
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14. The method of claim 11 in which the third party event data includes 
transaction authorisation data. 

15. The method of claim 12 in which the third digital signature is applied 
using a privat*e key of the third device, the counterpart public key being 
accessible to the first and second devices. 

. '9 

■ ■ . ** 

. 16. The method of claim 1 in which the first device is a portable 
10 identification device and the second device is an access control devicfe for 
controlling access to a building, facility or resource. 

1 7. The method of claim . 1 or claim 1 1 in which the signed full log includes 
the contents of the partial transaction log modified by.the second device. 
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18. The method of claim 1 or claim 1 1 further including the steps of. 
the first device issuing a revised transaction log to the second device, 

after receiving the signed full log, the revised partial log comprising the 
contents of the signed full log modified by the first device; and 

the second device issuing to the first device, in response to the revised 
partial log a revised signed full log secured by a digital signature specific to the 
second device. 

19. The method of claim 18 ftjrther including repeating the steps of issuing 
25 a revised partial transaction log and a revised signed full log until both the first 

and second devices are in agreement with the contents of the transaction log . 



20. A method of operating an access control device to generate a secure 
transaction log recording transaction data established between a first device 
and the access control device, comprising the steps of: 
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receiving from the first device, a partial transaction log, the partial 
transaction log including identification data and event data associated with the 
transaction; 

issuing to the first device, in response to the partial transaction log, a 
5 signed full log, the signed full log including said identification data and event 
data, secured by a first digital signature specific to the access control device; 
and 

receiving, from the first device, in response to the signed full log, a re- 
' signed full log including said identification data, said event data and sai^ first . 
10 digital signature, secured by a second digital signature specific to the first 
device. 

, 21 . The method of claim 20 further including the steps of: 

issuing a data request to a third device, after receiving the partial 
15 transaction log from the first device; 

receiving third party event data; from the third device in response to the 
data request; 

Including the third party event data into the signed full log issued to the 
first device. 

20 

22. The method of claim 20 or claim 21 in which the signed full log includes 
the contents of the partial transaction log modified by the second device, 

23. The method of claim 20 or claim 21 further including the steps of: 

25 the first device issuing a revised partial transaction log to the second 

device, after receiving the signed full log, the revised partial log comprising the 
contents of the signed full log modified by the first device; and 

the second device issuing to the first device, in response to the revised 
partial log a revised signed full log secured by a digital signature specific to the 

30 * second device. 
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♦ 

24. The method of claim 23 further including repeating the steps of issuing 
a revised partial transaction log and a revised signed fiJll log until both the first 
and second devices are in agreement with the contents of the transaction log. 

5 . 25. The method of claim 20 further including the step of verifying the 
* authenticity and integrity of the re-signed full log using a public key of the first 
device. 

.■ s 

26. The method of claim 20 or daim 21 in which the access control device 
' 10 is any of an electronic door lock, electronic gate look, equipment control 
system, computer system; data processing or retrieval system, point of sale 
terminal, or vending machine, and in which the first device Is any of an 
electronic key, credit or debit card. . .. 

15 27. The method of claim 20 further including the step of allowing the first 
device access to a predetermined resource, by the access control device, only 
after receipt of the re-signed log by the access control device. 

28. A method of operating a first data processing device to generate a 
20 secure transaction log recording transaction data established between the first 
' device and a second data processing device, comprising the steps of: 

issuing a partial transaction log to the second device, the partial 
tranggt'Tti ^ n i"g innlnrllng irifintifination date and event data associatea'witlTllTe' 
transaction; 

25 receiving from the second device, in response to the partial transaction 

log, a signed full log, the signed full log including said identification data and 
event data, secured by a first digital signature specific to the second device; 
and 

issuing, in response to the signed full log, a re-signed full log including 
30 said identification data, said event data and said first digital signature, secured 
by a second digital signature specific to the first device. 
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29. The method of claim 28 further including the step of verifying the 
authenticity and integrity of the signed full log using a public key of the second 
device. 

^^^^'^ computer program product, comprising a computer readable medium 
having thereon computer program code means adapted, when said program Is 
loaded onto a computer, to make the computer execute tfie procedure of any 

• one of claims 20 to 29. 

31. Apparatus for generating la secure transaction log recording transaction 
data established between a first and a second data processing device, 
comprising: 

means, In the first device, for issuing a partial transaction log to the 
second device, the partial transaction log including Identification data and 
event data associated with the transaction; 

means, In the second device, for issuing to the first device, in response 
to the partial transaction log, a signed full log, the signed full log Including said 
Identification data and event data, secured by a first digital signature specific to 
the second device; and 

means, in the first device, for issuing, in response to the signed full log, 
a re-signed full log including said identification data, said event data and said 
first digital signature, secured by a second digital signature specific to the first 
device. 

32. An access control device adapted to generate a secure transaction log 
recording transaction data established between a first device and the access 
control device, comprising: 

means for receiving from the first device, a partial transaction log, the 
partial transaction log including identification data and event data associated 
with the transaction; 

means for issuing to the first device, in response to the partial 
transaction log. a signed full log, the signed full log Including said identification 
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4 

data and event data, secured by a first digital signature specific to the access 

control device; and 

means for receiving, from the first device. In response to the signed full 
log, a re-signed full log including said identification data, said event data and 
5 said first digital signature, secured by a second digital signature specific to the 
first device. 

*33. A data processing device adapted to generate a secure transaction log 
recording transaction data established between the clata processing device 
10 and a second data processing device, comprising: 

means for Issuing a partial transaction log to the second device, the 
partial transaction log Including Identification data and event data associated 

with the transaction; .. ....... 

means for receiving from the second device, In response to the partial 
15 transaction log, a signed full log. the signed full log including said identification 
data and event data, secured by a first digital signature specific to the second 
device; and 

means for issuing, in response to the signed full log. a re-signed full log 
including said identification .data, said event data and said first digital 
20 signature, secured by a second digital signature specific to the data 
processing device. 




34 A m«=^thnH nf gp.neratlnq sTsecure transaaiofflg-g-Tgcgrdtng-transactlon- 
data established between a first and a second data processing device 
25 substantially as described herein with reference to the accompanying 
drawings. 

35. Apparatus substantially as described herein with reference to the 
accompanying drawings. 

30 
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ABSTRACT 

SECURE LOGGING OF TRANSACTIONS 

5 A method of generating a secure transaction log recording transaction 

data established between a first and a seconcJ data processing device. The 
transaction log includes transaction data derived from, the first device that Is 
digitally signed by the second device, anci then digitally re-signed by the firet 
d^vlce, with popies being stored locally to both devices. Any mtelference with 
10 the data by either device, or during transfer of data between them Is evident to 
both devices. The transaction data may include data received and signed by 
an independent third party as a trusted third party. 



15 



(Fig. 2) 



4-- 



Device 1 



51" Requ est 

Create Partial 



Log ' 



Sign Log 



20 

/ ■ 

Device 2 



Authentication/Negotiation 



PartialLog 



Signed FullLog ^ 



Re-SignedFuliLog 



S2 



54 CoiEplete Log & ' 
Sign • 



55 



Complete Transaction . 



1 



. Complete Transaction 



/ 



PH6rS 02.0 1^1 



3 4- 



(0 



Device 1 



Create Partial 



. Sign Log 



Device 2 



Auttientication/Negotiation 

<i : . 



PardalLog . 



Signed FuULog 



'\ Re-Signed PullLOg 



Time .Server 



62 



64n FinLog 



\^b6 Sign Log 



Complete Transaction 



1^^ ■ 
Complete Transactibn 



45 

Complete & 
Sign Log 



?VtGv2> 0:2-0 \Lv\ 



4 




4_. 



7 

30 



Oyptographic 
"V-— H Lock 



31 



20 



Bluetooth 
link 



Home Server . 



Inteinet 



Home Owner 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images witiiin this document are accurate representations of the original 
documents submitted by tfie applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 



□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




LINES OR MARKS ON ORIGINAL DOCUMENT 



^'^^FERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 



